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(57) ABSTRACT 

A method of automatically performing a component test at 
any number of locations in a distributed environment is 
disclosed. In general, in order to assure compatibility of the 
various components in an enterprise computing system, a 
service test is created as part of a compatibility test suite and 
passed to a test application server having a test application 
program. The test application program includes a gener ic 
vehi cle class that includes a plurality of vehicle class invo k- 
e rsjeach of which is used to implement each of the obj ect 
ty pes that are run in each of a p |nra]ify nf mntai'np,p During 
the build process of the CTS, each service test is automati- 
cally packaged with each of the appropriate vehicle classes 
so that each can be deployed into and run within the 
associated container. 

3 Claims, 4 Drawing Sheets 
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DISTRIBUTED COMPONENT TESTING IN 
AN ENTERPRISE COMPUTER SYSTEM 



BACKGROUND OF THE INVENTION 5 

1. Field of Invention 

The invention relates generally to computer systems. 
More particularly, methods and apparatus for distributed 
testing of components in an enterprise computer system. 

2. Description of Relevant Art 10 
Enterprises today need to extend their reach, reduce their 

costs, and lower their response times by providing easy-to- 
access services to their customers, partners, employees, and 
suppliers. Typically, applications that provide these services 
must combine existing enterprise information systems (EIS) 15 
with new business functions that deliver services to a broad 
range of users. These services need to be highly available in 
order to meet the needs of today's global business environ- 
ment secure so as to protect the privacy of users and the 
integrity of enterprise data, as well as both reliable and 20 
scalable to insure that business transactions are accurately 
and promptly processed. For a variety of reasons, these 
services are generally configured as distributed applications 
consisting of several tiers, including clients on the front end, 
data resources on the back end, and one or more middle tiers 25 
between them where the majority of the application devel- 
opment work is done. The middle tier implements the new 
services that integrate existing EISs with the business func- 
tions and data of the new service. The middle tier shields the 
client tier from the complexity of the enterprise and takes 3Q 
advantage of rapidly maturing Internet technologies to mini- 
mize user administration and training. 

One approach to constructing such an enterprise comput- 
ing system is to use component based, multi-tier applica- 
tions based on, for example, Java 2 Enterprise Edition 
(J2EE) technology from Sun Microsystems Inc. of Mountain 35 
View, Calif. As well known in the art, J2EE is a Java 
platform designed for the mainframe -scale computing typi- 
cal of large enterprises representing a multi-tier design that 
simplifies developing, deploying, and maintaining enterprise 
applications. In this regard, J2EE has been designed to 40 
simplify application development in a thin client tier envi- 
ronment by simplifying application development and 
decreasing the need for programming and programmer train- 
ing by creating standardized, reusable modular components 
and by enabling the tier to handle many aspects of program- 45 
ming automatically. It enables developers to focus on the 
specifics of programming their-business logic, relying on the 
J2EE server to provide system services, and client-side 
applications (both stand alone and within web browsers) to 
provide the user interaction. Once developed, business logic 5Q 
can be deployed on servers appropriate to existing needs of 
an organization. 

J2EE includes a number of components such as Enterprise 
JavaBeans (EJB) that is a server-based technology for the 
delivery of program components in an enterprise 
environment, Java servlet application program interfaces 
that enhances consistency for developers without requiring 
a graphical user interface, and Java Server Pages (that is the 
Java equivalent to Microsoft's Active Server Pages) is used 
for dynamic Web-enabled data access and manipulation. 

Compatibility is one of the keys to the success of the J2EE 60 
and one of the factors that make it so productive for IT 
organizations. With this in mind, J2EE platform vendors will 
need to verify that their implementations conform to the 
J2EE platform specification. Toward that end, what is 
referred to as a J2EE Compatibility Test Suite (CTS) has 65 
been developed by Sun Microsystems that ensures consis- 
tent implementation across various vendor offerings. For 



application developers, this means full portability for enter- 
prise applications. The CTS includes tests for all classes and 
methods required by the J2EE specification as well as 
end-to-end tests to check that all layers of a J2EE application 
will interact correctly and consistently. In this way, the CTS 
helps ensure that Enterprise JavaBeans components, Jav- 
aServer Pages, and servlets that run on one vendor's J2EE 
branded configuration will run on every J2EE branded 
configuration. In this way, the CTS assures enterprises and 
developers that APIs and development features are available 
in the branded implementation and work in a uniform way. 

Many of the tests included in the CTS are not end to end 
tests in that the test must be run at several locations (i.e., 
containers) since the Java specification defines several loca- 
tions from which some or all of the aforementioned APIs 
must be accessible which must be tested as part of the CTS. 
One such test is an API test that checks to make sure that a 
service AF1 (such as, lor exa mple, JDBC, JT A, JavaMai l, 
elc!) is implemented according to the Java specificatio n. 
Unfortunately, however, as currently conngured, a separate 
test must be written for each API in each J2EE container. By 
writing separate tests for every API in every container, a 
substantial amount of programming resources is wasted 
since substantially the same code is copied for every test so 
written. 

Therefore, in view of the foregoing, it would be advan- 
tageous and therefore desirable to have the capability of 
performing a distributed test in an enterprise computing 
environment such that a programmer would only be required 
to know the API for which the test is designed and not its 
particular location. 

SUMMARY OF THE INVENTION 

Broadly speaking, the invention relates to an improved 
method, apparatus and computer system for performing a 
distributed test in an enterprise computing environment. In 
one embodiment, a method of automatically performing a 
component test at any number of locations in a distributed 
environment is disclosed. In general, in order to assure 
compatibility of the various components in an enterprise 
computing system, a service test is created as part of a 
compatibility test suite and passed to a test application 
server having a test application program. The test applica- 
tion program includes a plurality of vehicle classes each of 
which is used to implement each of the object types that are 
run in each of a plurality of containers, such as, for example, 
a JSP vehicle, a servlet vehicle, and an EJB vehicle. During 
the build process of the CTS, each service test is automati- 
cally packaged with each of the appropriate vehicle classes 
so that each can be deployed into and run within the 
associated container. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The invention, together with further advantages thereof, 
may best be understood by reference to the following 
description taken in conjunction with the accompanying 
drawings in which: 

FIG. 1 shows a J2EE computing system test in accordance 
with an embodiment of the invention. 

FIG. 2 shows a flowchart detailing a process for deploying 
a test instance in a distributed computing environment. 

FIG. 3 is a flowchart detailing a process that is a particular 
implementation of the run operation shown in FIG. 2. 

FIG. 4 illustrates a computer system that can be employed 
to implement the present invention. 

DETAILED DESCRIPTION OF THE 
EMBODIMENTS 

Reference will now be made in detail to a preferred 
embodiment of the invention. An example of the preferred 
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embodiment is illustrated in the accompanying drawings. 
While the invention will be described in conjunction with a 
preferred embodiment, it will be understood that it is not 
intended to limit the invention to one preferred embodiment. 
To the contrary, it is intended to cover alternatives, 
modifications, and equivalents as may be included within 
the spirit and scope of the invention as defined by the 
appended claims. 

In general, in order to assure compatibility of the various 
components in an enterprise computing system, a service 
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t est (generally in the form of an API test) is created as par t 
of a compatibilityTesTsuite (or CTS) and passed to a test 
application server having a test application program. It 
should be noted, that the API test so created is location 
independent in that the API test does not comprehend any 
particular component (or location) and therefore includes 
code that can be re-used to test compatibility of any and all 
of the components so included. 

In the described embodiment, thfi lesLapplication program 
(sometimes referred to as a te~st harness ) inc ludes a pluralit y 
of vehicle classes each of which is used to implement ea ch 
of^e]ggectjt ypes (EJB, JSP, Servlet and Applicat ion 
c lient) tha "T"a re run" m each of the J2EE container s. In a 
preferred embodiment, during the build process, of the CTS, 
each service test is automatically packaged with an appro- 
priate vehicle class so that each can be deployed into and run 
within the associated J2EE container. 

For example, then the test application invokes a service 
/ test, an instance of the API test is created and passed to the \ 
/ appropriate vehicle which was deployed into a J2EE con- | 
1 tainer. Once inside the container, the test is run and the result A 0 
\is returned back to the test application. 

In this way, the invention allows for maximum code 
re-use as well as providing developers with the ability to 
focus on writing the s ervice API test while the actual runnin g 
ofth ejest is"maHaged'"by the inventive test a pplication usin g 
anappro pnate set or vehicle classe s. In addition to providing 
a m ore efficient approach to writing a n d executing ser vice 
t ests in a distributed environm ent, me invention allows for 
/the addition of new vehicle classes (if necessary) to run 
/ existing tests without the developer being required to 
V develop new code. 

Although, the invention will initially be described in 
terms of a J2EE based enterprise computer system, the 
present invention can be used in any networked computer 
system that requires any form of distributed component 
testin g. It should be noted that the JihiE application model 45 
divides enterprise applications into three fundamental parts: 
components, containers, and connectors. Components are 
the key focus of application developers, while system ven- 
dors implement containers and connectors to conceal com- 
plexity and promote portability. Containers intercede 
between clients and components, providing services trans- 
parently to both, including transaction support and resource 
pooling. Container mediation allows many component 
behaviors to be specified at deployment time, rather than in 
program code. Connectors sit beneath the J2EE platform, 
defining a portable service API to plug into existing enter- 
prise vendor offerings. Connectors promote flexibility by 
enabling a variety of implementations of specific services. 

With reference to FIG. 1, an enterprise computing system 
100 in accordance with an embodiment of the invention is 
shown. For the sake of this discussion, the enterprise com- 
puting system 100 is a J2EE system 100 but it should be 
noted that any component based distributed computing 
system can be used. In the described embodiment, the 
system 100 includes a client computer 102 coupled to a test 
application server computer 104. It should be noted that the 
client computer 102 can be used by a developer, for 
example, to code an API test 106 used to test various system 
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component characteristics. It should be noted that pure 
client-side user interfaces can use standard HTML and Java 
technology-based applets. Support for simple HTML means 
quicker prototypes, and support for a broader range of 
clients. 

The key to validating the Java 2Enterprise Edition is the 
J2EE Reference Implementation that provides all the speci- 
fied technologies, plus a range of sample applications, tools, 
and documentation. This lightweight implementation of the 
J2EE standard is provided for two purposes. First, it pro- 
vides system vendors with a standard by which to compare 
their own implementations. Second, it provides application 
developers with a way to familiarize themselves with J2EE 
technology as they explore commercial products for full- 
scale deployment of J2EE applications. Along these lines, 
the Compatibility Test Suite (CTS) ensures consistent imple- 
mentation across various vendor offerings. For application 
developers, this means full portability for enterprise appli- 
cations. The suite includes tests for all classes and methods 
required by the J2EE specification. It also includes end-to- 
end tests to check that all layers of a J2EE application will 
interact correctly and consistently. 

With this in mind, t he service test 106 is an API tes t 
i ncluded in a compatibility test suite (ITS) used to test the 
c ompliance of the system 100 to the J2EE Reference Imp le- 
mentation. In the described embodiment, the client computer 
102 includes a processor 108 used to perform executable 
instructions (i.e., software) stored in a memory 110 that 
takes the form of a test application 112, also referred to as 
a test harness. 

In a preferred embodiment, the test application server 104 
includes a plurality of containers 116-120 each of which 
contains an appropriate vehicle classe 128-132, respec- 
tively. For example, the container 116 is an EJB container 
116 that includes an EJB vehicle class 128. In the described 
embodiment, each of the vehicle classes 128-132 is used to 
implement an associated object type represented by, for — 
example, the various API tests 122-126. One such API test 
is an JDBC API 122, another is a JavaMail API 124, and yet 
another is a RMI-IIOP API 126. As well known in the art, 
business logic is encapsulated in Enterprise JavaBeans 
(EJB) components such that client interaction can be pre- 
sented through plain HTML web pages, through web pages 
powered by Java technology-based applets, Java Servlets 
API, or JavaServer Pages technology, or through stand-alone 
Java applications. Components communicate transparently 
using various standards: HTML, XML, HTTP, SSL, RMI, 
HOP, and others. 

In a preferred embodiment, during build time of the CTS, 
the API test 106 is automatically packaged with an appro- 
priate one of the plurality of vehicle classes so that each can 
be deployed into and run within the associated J2EE con- 
tainer when required. During runtime, the test application 
112 creates an instance of the API test 106 and passes that 
instance to any of the vehicles classes to be tested. Once the 
API test 106 is run, the result is passed back to the test 
application 112. It should also be noted that each of the API 
tests can be run from any of the vehicle classes. For 
example, the JDBC API test 122 can be run from the JSP 
vehicle and/or the servlet vehicle. Therefore in those cases 
when an additional test is coded, the developer need only 
code the particular test and not the locations where the test 
will be performed thereby saving substantial resources. 

FIG. 2 shows a flowchart detailing a process 200 for 
deploying a test instance in a distributed computing envi- 
ronment. The process 200 begins at 202 by configuring the 
application server to be tested. Typically, such configruation 
is directed at setting up the appropriate J2EE services to be 
tested, such as for example, setting up a WEB server and/or 
an EJB server. Once the application server has been 
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configured, the test to be performed is configured at 204 and 
the configured test is then begun at 206. At 208, a determi- 
nation is made whether or not the test being performed is an 
API test. If it is determined that the test is not and API test, 
then the test is an end to end test (end/end) and it is 
performed at 210. If, however, the test is determined to be 
an API test, then the location of the test is determined at 212 
and the test is run at the determined location at 214. At 216, 
the test results are written to a result file by the test 
application and at 218 the test result file is checked. 

FIG. 3 is a flowchart detailing a process 300 that is a 
particular implementation of the run operation 214 shown in 
FIG. 2. The process 300 begins at 302 by the test application 
creating an instance of the test client class. At 304, the test 
application — passes the instance to the determined location 
and at 306 the test client instance is run from the determined 
location. The result of the test is then returned at 308. 

FIG. 4 illustrates a computer system 400 that can be 
employed to implement the present invention. The computer 
system 400 or, more specifically, CPUs 402, may be 
arranged to support a virtual machine, as will be appreciated 
by those skilled in the art. As is well known in the art, ROM 
acts to transfer data and instructions uni-directionally to the 
CPUs 402, while RAM is used typically to transfer data and 
instructions in a bi-directional manner. CPUs 402 may 
generally include any number of processors. Both primary 
storage devices 404, 406 may include any suitable 
computer-readable media. A secondary storage medium 408, 
which is typically a mass memory device, is also coupled 
bi-directionally to CPUs 402 and provides additional data 
storage capacity. The mass memory device 408 is a 
computer-readable medium that may be used to store pro- 
grams including computer code, data, and the like. Typically, 
mass memory device 408 is a storage medium such as a hard 
disk or a tape which generally slower than primary storage 
devices 404, 406. Mass memory storage device 408 may 
take the form of a magnetic or paper tape reader or some 
other well-known device. It will be appreciated that the 
information retained within the mass memory device 408, 
may, in appropriate cases, be incorporated in standard fash- 
ion as part of RAM 406 as virtual memory. A specific 
primary storage device 404 such as a CD-ROM may also 
pass data uni-directionally to the CPUs 402. 

CPUs 402 are also coupled to one or more input/output 
devices 410 that may include, but are not. limited to, devices 
such as video monitors, track balls, mice, keyboards, 
microphones, touch-sensitive displays, transducer card 
readers, magnetic or paper tape readers, tablets, styluses, 
voice or handwriting recognizers, or other well-known input 
devices such as, of course, other computers. Finally, CPUs 
402 optionally may be coupled to a computer or telecom- 
munications network, e.g., an Internet network, or an intra- 
net network, using a network connection as shown generally 
at 412. With such a network connection, it is contemplated 
that the CPUs 402 might receive information from the 
network, or might output information to the network in the 
course of performing the above-described method steps. 
Such information, which is often represented as a sequence 
of instructions to be executed using CPUs 402, may be 
received from and outputted to the network, for example, in 
the form of a computer data signal embodied in a carrier 
wave. The above -described devices and materials will be 
familiar to those of skill in the computer hardware and 
software arts. 

It should be noted that the present invention employs 
various computer-implemented operations involving data 
stored in computer systems. These operations include, but 
are not limited to, those requiring physical manipulation of 
physical quantities. Usually, though not necessarily, these 
quantities take the form of electrical or magnetic signals 
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capable of being stored, transferred, combined, compared, 
and otherwise manipulated. The operations described herein 
that form part of the invention are useful machine opera- 
tions. The manipulations performed are often referred to in 

s terms, such as, producing, identifying, running, determining, 
comparing, executing, downloading, or detecting. It is some- 
times convenient, principally for reasons of common usage, 
to refer to these electrical or magnetic signals as bits, values, 
elements, variables, characters, data, or the like. It should 
remembered however, that all of these and similar terms are 

10 to be associated with the appropriate physical quantities and 
are merely convenient labels applied to these quantities. 

The present invention also relates to a device, system or 
apparatus for performing the aforementioned operations. 
Tne system may be specially constructed for the required 

15 purposes, or it may be a general-purpose computer selec- 
tively activated or configured by a computer program stored 
in the computer. The processes presented above are not 
inherently related to any particular computer or other com- 
puting apparatus. In particular, various general-purpose 
computers may be used with programs written in accordance 

20 with the teachings herein, or, alternatively, it may be more 
convenient to construct a more specialized computer system 
to perform the required operations. 

Although only a few embodiments of the present inven- 
tion have been described, it should be understood that the 

25 present invention may be embodied in many other specific 
forms without departing from the spirit or the scope of the 
present invention. 

Although the methods of performing a distributed test in 
an enterprise computing system in accordance with the 

30 present invention are particularly suitable for implementa- 
tion with respect to a Java™ based environment; the meth- 
ods may generally be applied in any suitable object-based 
environment. In particular, the methods are suitable for use 
in platform-independent object-based environments. It 

35 should be appreciated that the methods may also be imple- 
mented in some distributed object-oriented systems. 

It should also be appreciated that the present invention 
may generally be implemented on any suitable object- 
oriented computer system. Therefore, the present examples 

4 0 are to be considered as illustrative and not restrictive, and 
the invention is not to be limited to the details given herein, 
but may be modified within the scope of the appended 
claims along with their full scope of equivalents. 
What is claimed is: 

1. A method of performing a component test at any 
number of locations 

in a distributed environment, comprising: 
creating a service test; 

passing the service test to a test application server having 
5Q a test application program that includes a plurality of 
vehicle classes each of which is used to implement an 
associated object type that is run in each of a plurality 
of containers, 

automatically packaging the service test with an appro- 
priate one of the vehicle classes; 
55 deploying the packaged service test into the associated 
container; and 

running the packaged test in the associated container. 

2. A method as recited in claim 1, wherein the packaging 
is performed during the build process of a compatibility test 

60 suite (CTS), wherein the CTS is used to assure compatibility 
of the various components in an enterprise computing sys- 
tem. 

3. A method as recited in claim 2, wherein the plurality of 
vehicle classes includes a JSP vehicle, a servlet vehicle, and 

65 an EJB vehicle. 

* * + * « 
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